Add parallel fragments description#1490
Conversation
✅ Deploy Preview for streamlit-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
||
| When `parallel=True`, the behavior depends on the type of rerun: | ||
|
|
||
| - **During a full-app rerun**, Streamlit dispatches the fragment to a thread pool. It runs concurrently with your other parallel fragments and with the rest of your main script, rather than blocking on each fragment in turn. If `slow_chart` and `slow_table` each take two seconds, running them in parallel lets your app finish in about two seconds instead of four. |
There was a problem hiding this comment.
[nit] I am not super familiar with the formatting in the docs repo, but I am wondering if this should be unbolded? We should keep it consistent with the rest of the docs.
There was a problem hiding this comment.
You're right, I've removed the bold part to keep the style consistent.
|
|
||
| - **During a fragment rerun** (when a user interacts with a widget inside the fragment), execution stays sequential. The fragment runs by itself on the main thread, exactly like a non-parallel fragment. This keeps your state updates predictable when a user is actively interacting with a fragment. | ||
|
|
||
| Parallel fragments are most helpful when each fragment does independent, time-consuming work. If your fragments are fast or depend on each other's results, running them in parallel adds complexity without a meaningful speedup. |
There was a problem hiding this comment.
[suggestion] I think if they depend on each other's results it won't be possible to design the code with parallel fragments, perhaps we should drop that, or clarify that there is no mechanism to sync content between parallel fragments.
There was a problem hiding this comment.
I just removed this section, it doesn't add much to the explanation.
| - [`st.switch_page`](/develop/api-reference/navigation/st.switch_page) | ||
| - Writing to containers created outside the fragment. | ||
|
|
||
| These commands work normally during a fragment rerun (for example, after a user interacts with a widget inside the fragment), because fragment reruns are sequential. If you need one of these commands, call it from a non-parallel fragment or from the main body of your script. |
There was a problem hiding this comment.
[suggestion] Maybe we should give an example of how to run these from a fragment rerun. Basically, you can conditionally open a dialog based on a user interaction with the fragment (that would trigger a fragment rerun) but not open the dialog unconditionally in the fragment.
There was a problem hiding this comment.
I included a small code snippet explaining how to use them in a fragment rerun.
2 participants
📚 Context
Added a whole section in "Working with fragments" describing the behaviour of parallel fragments.
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.